The system behavior of a Central Processing Unit (CPU) when running different loads and when extended by a possible future system can be evaluated and predicted by measuring an idle value of the CPU. Conventionally, the idle value of the CPU (CPU idle value) of a traditional hard real-time operating system is obtained by running an idle task, also known as idle process, having the lowest priority. The idle task produces a dummy job such as incrementing a counter for a predetermined period of time (idle interval). The value of the counter after running the dummy job is then compared with a predetermined calibration value, which can be equal to a counter value when the idle task was run without any other simultaneous tasks. This approach can obtain a very precise idle value measurement.
A significant number of recently developed embedded systems included a CPU configured to operate a Linux-based operating system. However, Linux is not a hard real-time operating system; therefore, the above conventional approach to obtaining the CPU idle value cannot be used. Further, although Linux includes its own particular mechanism for measuring the CPU idle value, it does not work correctly on embedded systems because of a conflict with the design approach of Linux. Particularly, Linux is a UNIX-like system designed as a multitasking operating system for a desktop personal computer. The Linux kernel runs the idle task while there are no other tasks ready, and the CPU idle value measurement is based on system ticks with either 10 ms or 1 ms granularity. The Linux scheduler dedicates several system ticks for each task, and the CPU idle value measurement is based on the system ticks.
However, on an embedded system, each task may run on a fractional number of a system tick, thereby rendering the native Linux idle calculation based on system ticks inaccurate. For example, as shown in FIG. 3, an embedded system runs two very short tasks A and B. A scheduler controls the task switches, and decides how many fractional system ticks to dedicate for each of the task. However, because the tasks are scheduled in accordance with external hardware events, the tasks do not begin simultaneously with the system ticks (1, 2, 3, 4). The task accounting reads the same jiffy values at start and end of the tasks, and assumes that the tasks consume zero CPU. As a result, the accounting shows that the system is 100% idle, even though as shown in FIG. 3, the system may be up to 90% busy.
Therefore, what is needed is a method, system or apparatus for providing an accurate measurement of the CPU idle value in an embedded system.